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Abstract 


This  document  contains  the  software  requirements  analysis  for  a  prototype  of  Buylt.  As  a 
component  of  the  Corporate  Business  Application  Software  System  (C-BASS),  this  application 
automates  small  purchase  requests  (under  $2,500).  The  document  follows  the  process  of 
structured  analysis,  or  step-wise  refinement  of  requirements,  as  applied  to  the  development  of 
Buylt.  The  “environmental  model”  includes  a  high-level  system  description,  followed  by  a 
context  diagram  and  a  list  of  events  to  which  the  system  must  respond.  The  “behavioral  model” 
includes  a  data  flow  diagram  (DFD)  for  each  of  the  seven  Buylt  subsystems.  From  this 
representation,  the  basic  functional  specifications  are  derived  and  represented  in  structured 
English  (or  program  design  language).  The  final  segment  of  the  document  includes  a  data 
dictionary. 
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1.  Introduction 


Buylt  is  a  component  of  the  Corporate  Business  Application  Software  System  (C-BASS) 
family  of  applications,  an  integrated  set  of  Lotus  Notes  and  Web-based  software  to  support 
U.S.  Army  Research  Laboratory  (ARL)  electronic  workflow  and  task  automation.  The 
motivating  force  behind  this  project  has  been  ARL  downsizing  and  findings  put  forth  in  the 
Business  Process  Reengineering  (BPR)  report  on  the  small  purchase  process.  The  BPR  ‘To-Be 
Model:  Small  Purchase”  [1]  identifies  potential  process  improvements — some  of  which  require 
computer  automation— that  would  increase  productivity  of  purchasing  operations  at  ARL. 
Development  of  a  full-production  Buylt  will  proceed  in  phases,  using  an  incremental,  evolutionary 
approach. 

1.1  Buylt  Prototype.  The  purpose  of  the  Buylt  prototype  project  is  to  model  a  secure 
client/server  system  that  provides  for  the  processing  of  small  purchase  requests.  This  proof-of- 
principle  prototype  will  alleviate  some  of  the  risks  involved  in  implementing  new  technologies 
used  to  build  the  ARL  Intranet.  The  project  will  also  refine  requirements  described  in  the  ARL 
Business  Process  Reengineering  (BPR)  ‘To-Be  Model”  [1]. 

1.2  Development  Plan  and  Project  Schedule.  The  “Buylt  Software  Development  Plan  [2] 
states  a  definition  of  the  problem;  gives  an  overview  of  technical,  management,  and  reliability 
issues;  and  provides  a  detailed  project  schedule.  The  report  enclosed  herein  covers  the  work 
accomplished  to  solidify  user  requirements  (drawn  from  existing  high-level  design  documents)  and 
the  analytical  expansions  used  to  derive  a  data  flow  model,  a  pseudocode  representation  of 
processing,  and  a  data  dictionary.  As  stated  in  the  project  schedule,  the  analysis  represents  a 
10- working-day  effort  and  was  completed  within  the  stated  timeframe  of  13  January  1997  to 
27  January  1997. 

1.3  Contents  of  This  Report.  This  document  presents  the  results  of  a  structured  system 
analysis  used  to  derive  the  software  requirements  for  Buylt,  starting  with  the  baseline  given  in  the 
BPR  ‘To-Be  Model:  Small  Purchase”  [1].  The  body  of  the  report  contains  five  sections. 
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•  Structured  Analysis  Overview  -  briefly  explains  the  methodology  used  to  extract  the 
software  functional  specifications. 

•  System  Overview  -  delineates  the  basic  Buylt  concept  and  outlines  the  high-level 
requirements. 

•  Requirements  -  breaks  the  generic  statements  into  low-level,  derived  requirements  and 
describes  each  in  detail. 

•  Functional  Specifications  -  discusses  the  products  of  the  structured  analysis  (i.e.,  the  data 
flow  diagrams  and  structured  English  narrative)  for  each  subsystem  of  Buylt. 

•  Data  Dictionary  -  lists  each  of  the  Buylt  data  elements,  giving  a  full  description  and  type  for 
the  data  model. 

2.  Structured  Analysis  Overview 

Modem  software  engineering  utilizes  structured  analysis  [3]  as  a  powerful  methodology  for 
developing  system  specifications.  Through  a  series  of  step-wise  refinements,  detailed  delineations 
of  the  system’s  components  and  their  behavior  are  extracted  from  high-level  descriptions  of 
system  features  and  functions.  In  other  words,  primary  system  elements  are  broken  down  into 
progressively  more  detailed  levels  of  processes,  and  the  data  paths  between  these  processes  are 
defined.  Three  modeling  tools  facilitate  this  decomposition:  (1)  data  flow  diagrams  (DFDs),  (2) 
structured  English  process  narratives  (pseudocode  or  program  design  language  [PDL]),  and  (3)  a 
data  dictionary.  Accuracy  and  precision  in  progressively  expanding  design  definitions  are  critical 
to  successful  system  development. 

The  results  of  this  analytical  approach  are  systematic  elaborations  of  product  requirements, 
typically  expressed  as  two  separate  models: 

•  An  environmental  model  that  defines  the  system’s  interfaces  to  the  outside  world.  (See 
section  3,  “System  Overview.”) 
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•  A  behavioral  model  that  defines  the  internal  behavior  the  system  must  exhibit  in  order  to 
deal  with  the  environment.  (See  section  4,  “System  Requirements,”  and  section  5, 
“Functional  Specifications.”) 

3.  System  Overview 

The  environmental  model  typically  consists  of  three  components:  (1)  a  concise  statement  of 
the  system’s  purpose  or  required  functionality,  (2)  a  context  diagram,  and  (3)  an  events  list.  The 
context  diagram  is  the  highest  level  DFD.  It  shows  the  system  as  a  single  process,  including  user 
interaction  and  communication  with  external  systems,  as  well  as  data  flow  input  and  output.  The 
events  list  creates  an  index  of  outside  stimuli  to  which  the  system  responds. 

3.1  Required  Functionality.  As  a  system,  the  Buylt  prototype  provides  a  secure, 
automated  means  for  the  preparation,  routing,  approval,  tracking,  and  reporting  of  small  purchase 
requests.  Table  1  lists  the  high-level  requirements  for  the  Buylt  prototype  and  a  general 
description  of  what  each  requirement  involves. 

3.2  Context  Diagram.  Figure  1  shows  the  context  diagram  for  the  prototype.  Each  square 
in  the  diagram  represents  an  external  entity  (e.g.  users,  functional  areas,  and  legacy  systems)  with 
which  Buylt  communicates.  The  arrows  indicate  the  data  that  flow  into  and  out  of  Buylt.  A  few 
elements  on  the  DFD  need  additional  explanation.  First,  the  external  entity  “User”  represents  all 
users  of  the  system,  and  the  data  flow  associated  with  this  box  is  limited  to  display  of  information. 
Second,  all  the  other  external  entities  (e.g.,  “Requester”  and  “Supervisor”),  and  their 
corresponding  data  flow,  show  the  specific  information  that  is  passed  to  Buylt  either  by  that  user 
or  by  the  system.  Lastly,  the  data  store  EMPLOYEE  contains  user  information  such  as  name, 
phone  number,  address,  office  symbol,  etc. 
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Table  1.  High-Level  Requirements  for  the  Buylt  Prototype 


Requirement 

General  Description  I 

Security 

Provide  security  measures  to  prevent  unauthorized  access  to 
the  system  and  its  data  and  keep  authorized  users  from 
performing  tasks  not  allowed  in  their  roles. 

Purchase  request  preparation 

Provide  a  means  for  the  requesters  and  functional  users  to 
input/edit  relevant  information  pertaining  to  a  purchase 
request. 

Automated  request  routing 

Automate  the  process  of  routing  purchase  requests  to  the 
various  functional  areas. 

Electronic  approval 

Provide  a  means  for  approving  officials  and  functional  users  to 
electronically  approve  or  reject  a  purchase  request. 

Receive/Accept  order 

Provide  a  means  for  Receiving  to  notify  requesters  of  shipment 
arrival  and  for  the  purchaser  to  accept  or  decline  the  order. 

Request  tracking 

Allow  users  to  track  the  status  of  active  purchase  requests 
currently  in  the  system. 

Legacy  system  interface 

Implement  automated  interfaces  to  SOMARDS  and 
SAACONS  legacy  systems. 

Reporting 

Provide  users  and  management  with  a  means  for  reporting 
cycle  times  and  costs. 

3.3  Event  List  The  following  list  contains  events  to  which  the  system  must  respond. 

•  Requester  initiates  new  purchase  request. 

•  Requester  prepares  request. 

•  Requester  corrects  rejected  request. 

•  Requester,  supervisor,  or  budget  analyst  completes  fund  source. 

•  Requester  or  supervisor  cancels  request. 

•  Budget  analyst  certifies  fund  source. 

•  SOMARDS  certifies  and  commits  funds. 

•  Special  approving  official(s)  approves  request  item(s). 

•  Property  book  officer  attaches  item  tags. 

•  Property  book  officer  approves  request. 

•  Contracting  officer  assigns  buyer  to  request. 

•  SAACONS  downloads  purchase  order  information. 

•  Supervisor  approves  actual  costs. 

•  Receiving  marks  shipment  as  received. 
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•  Receiving  checks  off  tagged  items. 

•  Requester  accepts  shipment. 

•  User  submit  status  inquiry. 

•  User  request  report. 


4.  System  Requirements 


Antecedent  studies  and  legacy  systems  also  contribute  to  Buylt’s  requirements.  The 
“Automation  Requirements”  [4]  and  the  ‘To-Be  Model:  Small  Purchase”  [1]  were  produced 
during  the  BPR  development  effort.  However,  for  some  areas,  these  documents  lack  detail,  and 
necessary  elements  had  to  be  derived.  Additionally,  the  limited  scope  of  a  prototype  necessitated 
leaving  out  some  of  the  more  complicated  or  vague  automation  requirements  of  the  ‘To-Be 
Model”  (e.g.,  a  pull-down  product  selection)  or  areas  where  the  requirement  already  exists  in  a 
Department  of  Defense  (DOD)  standard  system  (e.g.,  functionalities  handled  by  SAACONS). 
“Buylt:  Software  Development  Plan”  [2]  more  fully  addresses  the  constraints  on  the  prototype 
and  the  requirements  of  legacy  systems. 

El  Security 

Ell  Prevent  unauthorized  access 

Description  —  Prevent  unauthorized  access  to  the  system  and  its  data. 
Source  —  Derived,  due  to  the  nature  of  the  system. 

Interfaces  to  major  functions  and  external  entities: 

User. 

E12  Enforce  role  restrictions 

Description  —  Prevent  users  from  performing  tasks  or  accessing/editing 
data  that  are  out  of  the  scope  of  their  role. 

Source  —  BPR  ‘To-Be  Model”  document,  Automation  Requirements 
section,  requirement  A12. 

Interfaces  to  major  functions  and  external  entities: 
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User. 

Approvals. 

Edits. 

Employee  address  book  (for  roles). 

E2  Purchase  request  preparation 

E21  Create  new  purchase  request 

Description  -  Allow  the  requester  to  create  a  new  purchase  request  with 
preliminary  user  information  filled- in 

Source  ~  BPR  “To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A1 1 1  and  A1 14. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

Employee  address  book  (for  user  info). 

E22  Select  items 

Description  —  Provide  a  means  for  the  requester  to  enter  item  descriptions, 
specifications,  quantities,  and  estimated  costs. 

Source  -  BPR  ‘To-Be  Model”  document,  Automation  Requirements 
section,  requirement  All 2. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E23  Complete  purchase  request 

Description  -  Provide  a  means  for  the  requester  and/or  approving 
supervisor  to  complete  the  purchase  request. 

Source  -  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A1 14. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 


7 


E24  Item  tag  input 

Description  —  Provide  a  means  for  the  Property  Book  Officer  to  enter  item 
tags. 

Source  -  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A1 13. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E25  Edit  purchase  request 

Description  —  Provide  a  means  for  users  to  edit  certain  request  details  as 
needed. 

Source  —  Derived,  due  to  the  need  for  making  corrections  to  rejected 
purchase  request. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E3  Automated  routing 

Description  -  Automate  the  process  of  routing  purchase  requests  to  the 
various  functional  areas  and  approving  officials. 

Source  «  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A12. 

Interfaces  to  major  functions  and  external  entities: 

Security. 

Employee  address  book  (for  default  routing). 

E4  Electronic  approval 

Description  —  Provide  a  means  for  approving  officials  and  functional  users 
to  approve  or  reject  a  purchase  request. 

Source  -  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A12. 

Interfaces  to  major  functions  and  external  entities: 
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User. 

Security. 

E5  Receive/Accept  order 
E51  Receive  shipment 

Description  -  Provide  a  means  for  Receiving  to  notify  purchasers  of 
shipment  arrival. 

Source  -  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A12.  . 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E52 

E53  Tag  item 

Description  -  Provide  a  means  for  Receiving  to  attach  item  tags  to  received 
items. 

Source  -  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A3. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E54  Accept  shipment 

Description  -  Provide  a  means  for  the  requester  to  accept  or  decline  the 
order  or  items. 

Source  —  BPR  ‘To-Be  Model”  document,  “Automation  Requirements” 
section,  requirements  A31. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E6  Request  tracking 

Description  —  Allow  users  to  track  the  status  of  active  purchase  requests 
currently  in  the  system. 


9 


Source  —  User  requested. 

Interfaces  to  major  functions  and  external  entities: 

User. 

E7  Legacy  system  interfaces 

E71  Budget  legacy  system  interface 

Description  -  Provide  an  electronic  interface  to  the  legacy  financial  system 
(SOMARDS)  that  automates  the  certification  and  commitment  of  funds. 
Source  -  BPR,  ‘To-Be  Model”  section,  process  model  diagram  A12, 
process  A122. 

E72 

E73  Procurement  legacy  system  interface 

Description  -  Provide  an  electronic  interface  to  the  legacy  procurement 
system  (SAACONS)  that  automates  the  uploading  of  request  information  to 
that  system  and  the  download  of  purchase  order  data. 

Source  -  Derived.  SAACONS  is  the  primary  tool  the  buyers  use  during  the 
procurement  process;  therefore,  there  is  a  definite  need  for  interfacing  with 
this  legacy  system  in  order  to  eliminate  the  need  for  double  entry  into  both 
Buylt  and  SAACONS. 

E8  Reporting 

Description  —  Provide  users  and  management  with  a  means  for  reporting 
cycle  times  and  costs. 

Source  -  BPR  “Reports  Specifications”  document. 

Interfaces  to  major  functions  and  external  entities: 

User. 

Security. 

E9  Navigation 

Description  —  Provide  users  with  a  means  for  navigating  to  the  various 
functional  areas  within  the  system. 

Source  -  Derived  from  the  requirements  previously  listed. 

Interfaces  to  major  functions  and  external  entities: 

User. 
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5.  Functional  Specifications 


The  behavioral  model  expands  the  analytical  results  from  the  environmental  model  to  more 
fully  define  how  the  system  performs  prescribed  tasks.  Typical  representations  in  this  model  are 
(1)  concise  flowcharts  showing  how  information  is  transformed  as  it  moves  through  the  system 
and  subsystems,  (2)  a  set  of  structured  English  statements  that  form  a  processing  narration  based 
on  data  types,  control  structures,  and  transformations,  and  (3)  a  data  dictionary  defining  each  data 
item 


5.1  Buylt  Subsystems.  The  nine  functionalities  listed  in  the  previous  section  identify  the 
major  components  of  Buylt:  (1)  security,  (2)  request  preparation,  (3)  automated  routing,  (4) 
electronic  approval,  (5)  status  tracking,  (6)  receive/accept  notification,  (7)  legacy  system 
interfaces,  (8)  report  generation,  and  (9)  navigation.  These  categories  consolidate  into  seven 
subsystems. 

Figure  2  shows  the  major  functional  subsystems  of  Buylt,  as  represented  by  a  DFD.  Each  of 
the  seven  bubbles  in  the  diagram  represents  a  major  subsystem  or  process  of  Buylt,  with  the 
arrows  showing  the  data  flowing  into  and  out  of  the  processes. 

The  data  store  ACTIVE — located  in  the  center  of  the  diagram — holds  all  the  active  purchase 
requests,  each  waiting  for  the  appropriate  users  to  perform  their  functions  on  them  The 
CLOSED  and  CANCELED  data  stores  contain  purchase  requests  that  have  been  closed  out  or 
canceled,  respectively.  The  small  squares  along  the  outer  edges  of  this  DFD  are  interfaces  to  the 
outside  world. 

No  process  bubble  for  security  appears  at  this  level  because  the  application  environment  (i.e., 
Lotus  Notes)  handles  unauthorized  user  security.  Additionally,  enforcement  of  role  restrictions  is 
handled  within  each  subsystem,  as  detailed  in  the  following  section. 
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5.2  Subsystems  Data  Flow  Diagrams.  System  objects  and  operations  can  be  coherently 
represented  as  data  flow  diagrams  (DFDs).  A  DFD  can  be  used  to  capture  system  concepts  and 
components  at  any  level  of  abstraction.  Each  of  the  following  seven  DFDs  (Figures  3  through  9) 
provides  more  detail  for  the  information  flow  and  functionality  of  each  of  the  identified  Buylt 
subsystems. 

Figure  3  represents  the  DFD  for  the  Prepare  Purchase  Request  subsystem.  The  major  inputs 
to  this  process  (and  its  basic  functions)  are  the  requester  information  (derived  from  the 
user-supplied  userid  and  the  EMPLOYEE  data  store),  item  details,  vendor  information  (if  known 
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Figure  3.  Prepare  Purchase  Request  Process. 

at  this  time),  and  the  date  by  which  the  items  are  required.  The  fund  source  completes  the 
information  for  the  request,  and  the  supervisory  approval  puts  the  request  into  the  procurement 
cycle. 

Figure  4  shows  the  DFD  for  the  Approve  Funds  subsystem.  This  subsystem,  besides  having 
interfaces  to  users  for  approvals,  also  has  connections  to  the  SOMARDS  legacy  system.  The 
Build  Block  process  is  executed  at  the  start  of  the  day  and  creates  the  transaction  block  that  will 
be  used  by  Buylt  for  the  remainder  of  the  day.  As  certified  purchase  requests  are  created  during 
the  course  of  the  day,  the  Certify  Funds  process  queries  SOMARDS  and  grabs  the  returning 
message.  Depending  on  the  results  of  this  query,  the  request  is  either  certified  or  rejected  (with 
explanation).  At  the  end  of  the  day,  the  Reconcile  process  is  executed  to  balance  the  transaction 
block. 

The  Approvals  process  is  shown  in  Figure  5.  At  this  point,  the  various  approving  officials 
attach  their  approval  or  rejection  to  the  request.  The  property  book  officer  also  attaches  item  tags 
to  the  individual  items  in  order  to  flag  them  during  receipt  of  the  shipment. 
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Figure  4.  Approve  Funds  Process. 


Figure  5.  Approvals  Process. 
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Figure  6  diagrams  the  Edit  Purchase  Request  process.  The  rejected  purchase  request  is 
displayed  for  the  requester,  who  then  enters  the  corrections.  What  fields  within  the  request  the 
user  can  edit  depends  on  where  the  rejection  came  from  and  how  far  along  in  the  approval  process 
the  request  traveled. 


Figure  6.  Edit  Purchase  Request  Process. 

The  Prepare  Purchase  Order  process  is  diagramed  in  Figure  7.  The  first  step  of  the  process  is 
assigning  a  buyer.  This  triggers  the  upload  of  the  purchase  request  information  to  SAACONS. 
The  buyer  then  proceeds  to  work  within  SAACONS.  The  second  part  of  the  SAACONS 
interface  is  the  downloading  of  information  (actual  costs,  selected  vendor,  delivery  date).  The 
request  is  then  forwarded  to  Receiving  in  order  to  alert  that  office  of  the  pending  shipment. 


Figure  7.  Prepare  Purchase  Order  Process. 
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Figure  8  represents  the  Receive  Shipment  process.  Once  the  shipment  has  been  delivered  to 
the  warehouse,  Receiving  marks  the  request  as  received  and  checks  off  any  tagged  items  once 
each  has  been  properly  accounted  for.  At  this  point,  the  system  notifies  the  requester  of  receipt 
and  allows  the  user  to  accept  or  return  items  once  they  have  been  delivered. 


Figure  8.  Receive  Shipment  Process. 


The  Inquires  process  is  diagramed  in  Figure  9.  The  processes  shown  in  this  figure  are  used  to 
display  to  the  user  (1)  pending  actions  (inbox),  (2)  purchase  request  details,  (3)  the  status  of 
requests,  and  (4)  reports. 


Figure  9.  Inquires  Process. 
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5.3  Processing  Narration.  Having  captured  the  flow  of  information  and  identified  data 
objects,  each  transformation  can  be  further  expanded  by  using  the  stylized  notation  of  structured 
English.  Basic  procedural  constructs  are  combined  with  English  phrases  to  give  concise 
descriptions  for  each  major  operation  listed  in  the  prescribed  tasks  analysis  given  in  section  4. 

El  Security 

Ell  Login 

Input  —  userid,  passwd 
Process: 

REPEAT 

GET  from  user  the  userid,  passwd 
UNTIL  VALID  userid,  passwd 
ALLOW  login 
Output  —  N/A 

E12  Role 

Input  —  role,  action 
Process 

GET  from  EMPLOYEE  the  role  using  requester_userid 
IF  VALID  action  for  role  THEN 
EXECUTE  action 

ELSE 

NULL 

ENDIF 

Output  —  action_results 

E2  Prepare  purchase  request  for  ordering 
E21  Create  new  purchase  request 

Input  —  pr,  requester_userid,  user_info 
Process  1.1 
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GET  from  EMPLOYEE  the  user_info  using 

requester_userid 

SET  in  pr  the  requester_userid 
SET  in  pr  the  user_info  using  user_info 
Output  -  blank_pr 
E22  Fill  in  purchase  request 

Input  -  blank_pr,  priority_code,  items,  vendors,  date_required 
Process  1.2 

GET  from  user  the  priority_code 
SET  in  pr  the  priority_code 
DO  WHILE  there  is  another  item  to  add 
GET  from  user  the  item 
SET  in  pr  the  item 
ENDDO 

GET  from  user  the  specifications 
SET  in  pr  the  specifications 
DO  WHILE  there  is  another  vendor  to  add 
GET  from  user  the  vendor 
SET  in  pr  the  vendor 
ENDDO 

GET  from  user  the  date_required 
SET  in  pr  the  date_required 
Output  —  partial_pr 
E23  Fill  in  fund  source 

Input  -  partial_pr,  fund_source 
Process  1.3 

GET  from  user  the  fund_source 
SET  in  pr  the  fund_source 
Output  —  funded_pr 
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E3 


E24  Correct  purchase  request 

Input  -  rejectecLpr,  corrections 
Process  4.1 

DISPLAY  to  user  rejected_pr  and  explanation 
DO  WHILE  there  are  more  corrections 
GET  from  user  the  corrections 
SET  in  pr  the  corrections 
ENDDO 

Output  —  corrected_pr 
E25  Attach  item  tags 

Input  -  special_pr,  item_tag 
Process  3.2 

DO  WHILE  there  are  more  items  to  tag 
GET  from  user  item_tag 
SET  in  pr  the  item_tag 
ENDDO 

Output  —  taggable_pr 
E26  Cancel  request 

Input  —  active_pr,  cancel_order 
Process  4.2 

DISPLAY  to  user  the  active_pr 
GET  from  user  the  cancel_order 
PUT  canceledjpr  into  CANCELED 
Output  —  canceled_pr 

Routing 

E31  Automated  routing 

Input  —  active_pr 
Process  —  TBD 
Output  —  active_pr 
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E32  Manual  routing 

Input  -  active_pr 
Process  —  TBD 
Output  -  active_pr 
E33  Assign  Buyer 

Input  —  orderable_pr 
Process  5.1 

DISPLAY  to  user  the  orderable_pr 
GET  from  user  the  buyer_assignment 
SET  in  pr  the  buyer_assignment 
SET  in  pr  the  inbox_location  to  buyer 
Output  —  assigned_pr 

E4  Approvals 

E41  Supervisory  approval 

Input  -  funded_pr,  supervisory_approval 
Process  1.4 

DISPLAY  to  user  the  fiinded_pr 
GET  from  user  the  supervisory_approval 
IF  supervisory_approval  is  “Yes”  THEN 

SET  in  pr  the  supervisory_approval  to  “Yes” 
SET  in  pr  the  request_date  to  today’s  date 
SET  in  pr  the  inbox_location  to  budget 

ELSE 

GET  from  user  the  explanation 

SET  in  pr  the  supervisory_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox  location  to  requester 

ENDIF 

Output  -  completed_pr,  rejected_pr 
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E42  Fund  source  approval 

Input  -  completed_pr,  fund_source_approval 
Process  2.1 

DISPLAY  to  user  the  completed_pr 
GET  from  user  the  fund_source_approval 
IF  fund_source_approval  is  “Yes”  THEN 

SET  in  pr  the  fund_source_approval  to  “Yes” 
SET  in  pr  the  inbox_location  to  certification 

ELSE 

GET  from  user  the  explanation 

SET  in  pr  the  fund_source_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  —  certifiable_pr,  rejected_pr 
E43  Special  approval 

Input  -  certified_pr,  special_approval 
Process  3.1 

DISPLAY  to  user  the  certifiedjpr 
GET  from  user  the  special_approval 
IF  special_approval  is  “Yes”  THEN 

SET  in  pr  the  special_approval  to  “Yes” 

SET  in  pr  the  inbox_location  to 

property_book_officer 

ELSE 

GET  from  user  the  explanation 
SET  in  pr  the  special_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  -  special_pr,  rejected_pr 
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E44  Property  approval 

Input  -  special_pr,  property_approval 
Process  3.3 

DISPLAY  to  user  special_pr 
GET  from  user  property_approval 
IF  property_approval  is  “Yes”  THEN 

SET  in  pr  the  property_approval  to  “Yes” 
SET  inbox_location  to  contracting_officer 

ELSE 

GET  from  user  explanation 

SET  in  pr  the  property_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  —  orderable_pr,  rejected_pr 
E45  Actual  cost  approval 

Input  —  actual_pr,  actual_cost_approval,  explanation 
Process  2.2 

DISPLAY  to  user  actual_pr 

GET  from  user  actual_cost_approval 

IF  actual_cost_approval  is  “Yes”  THEN 

SET  in  pr  the  actual_cost_approval  to  “Yes” 
SET  in  pr  the  inbox_location  to  buyer 

ELSE 

GET  from  user  explanation 

SET  in  pr  the  actual_cost_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  -  certifiable_pr,  rejected_pr 
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E46  Buyer  approval 

Input  —  assigned_pr,  buyer_approval,  explanation 
Process  2.2 

DISPLAY  to  user  assigned_pr 
GET  from  user  the  buyer_approval 
IF  buyer_approval  is  “Yes”  THEN 

SET  in  pr  the  buyer_approval  to  “Yes” 

ELSE 

GET  from  user  explanation 

SET  in  pr  the  buyer_approval  to  “No” 

SET  in  pr  the  explanation 

SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  -  approvecLpr,  rejected_pr 
E5  Interface  with  legacy  systems 
E51  Build  block 

Input  —  N/A 
Process  2.3 

PUT  to  SOMARDS  the  block 
GET  from  SOMARDS  the  retum_message 
Output  —  N/A 
E52  Certify  funds 

Input  -  certifiable_pr 
Process  2.4 

GET  from  certlfiable_pr  the  funds 
PUT  to  SOMARDS  the  block,  funds 
GET  from  SOMARDS  the  retum_message 
IF  retura_message  is  “OK”  THEN 

SET  in  pr  the  certification  to  “Yes” 

SET  in  pr  the  inbox_location  to  special_approval 
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ELSE 


SET  in  pr  the  to  certification  to  “No” 

SET  in  pr  the  explanation  to  retum_message 
SET  in  pr  the  inbox_location  to  requester 

ENDIF 

Output  -  certified_pr,  rejected_pr 
E53  Reconcile 

Input  —  N/A 
Process  2.5 

PUT  to  SOMARDS  the  block,  reconcile 
GET  from  SOMARDS  the  retum  message 
Output  —  N/A 
E54  Upload  to  SAACONS 

Input  -  assigned_pr 
Process  5.1 

GET  from  assigned  jjr  the  upload 
PUT  to  SAACONS  the  upload 
Output  —  N/A 

E55  Download  from  SAACONS 

Input  —  assigned_pr,  actual_cost,  vendor,  delivery_date,  po_number 

Process  5.3, 5.4 

GET  from  SAACONS  the  award 
IF  total_actual_cost  are  greater  than 

totalestimatedcost  THEN 
SET  in  pr  the  explanation  to  “Actual  cost  greater” 

SET  in  pr  the  inbox_location  to  supervisor 

ENDIF 

GET  from  SAACONS  the  award 

SET  in  pr  the  vendor,  delivery_date,  po_number,  award  date 
SET  in  pr  the  inbox_location  to  receiving 
Output  —  ordered_pr,  actual_pr 
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E6  Receive  shipment 

E61  Receive  shipment 

Input  —  ordered_pr,  receipt 
Process  6.1 

DISPLAY  to  user  the  ordered_pr 
GET  from  user  the  receipt 
SET  in  pr  the  receipt 
Output  —  received_pr 

E62 

E63  Check  off  taggable  items 

Input  —  received_pr,  item_tag 
Process  6.2 

DISPLAY  to  user  receivedjpr 
FOR  EACH  item  in  received_pr 

IF  item_tag  is  “Yes”  THEN 

GET  from  user  the  item_tag 
SET  in  pr  the  item_tag 

ENDIF 

ENDFOR 

SET  in  pr  the  inbox_location  to  requester 
Output  —  tagged_pr 
E64  Accept  shipment 

Input  -  tagged_pr,  acceptance 
Process  6.3 

DISPLAY  to  user  tagged_pr 
FOR  EACH  item  in  tagged_pr 

GET  from  user  the  acceptance 
IF  acceptance  is  “No”  THEN 

GET  from  user  the  explanation 
SET  in  pr  the  explanation 

ENDIF 
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ENDFOR 

PUT  closed_pr  into  CLOSED 
Output  —  closed_pr 
E7  Status  inquires 

Input  —  active_pr 
Process  7.3 

GET  current  status  from  ACTIVE 

DISPLAY  to  user  the  status 
Output  --  status 
E8  Generate  reports 

Input  -  report_type 
Process  7.4  —  TBD 
Output  —  report 

E9  Navigation 

E91  Navigate 

Input  —  TBD 
Process  —  TBD 
Output  —  TBD 
E92  Logout 

Input  —  N/A 
Process  -  TBD 
Output  —  N/A 

6.  Data  Dictionary 


While  DFDs  and  pseudocode  (structured  English)  are  important  to  system  specification, 
additional  information  is  required  for  a  complete  analytical  model.  The  content  of  each  data  or 
control  item  should  be  more  fully  identified.  A  data  dictionary  is  a  quasi-formalism  for  describing 
content  of  information  as  it  flows  through  the  system.  The  standard  notation  conventions  are 
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Notation 


[|] 

{  >n 

(  ) 

*  * 


Meaning 

is  composed  of 
and 

either/or 
n  repetitions  of 
optional  data 
comments 


Buylt  prototype’s  data  dictionary  follows.  Each  left-hand  element  is  taken  from  the  DFD 
and  the  Process  Narrative  representations  of  the  system.  These  data  items  are  then  given  an 
expanded,  unambiguous  definition  in  the  right-hand  column. 


acceptance  = 


♦requester  accepts  or  returns  shipment  item* 
[“Yes”  I  “No”] 


ACTIVE  = 


{active_pr> 


action  = 


** 

TBD 


action_results  = 


TBD 


active_pr  = 


♦purchase  request  at  some  point  in  the  approval  cycle* 


actual_cost  = 


♦actual  cost  of  an  item* 
♦units:  dollars* 


actual_cost_approval  =  *supervisory  approval  of  the  total  actual  cost  of  the 

request* 

[“Yes”  I  “No”] 
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actual_pr  = 


address  = 


al_cost  = 


aLregdeld  = 


approved_pr  = 


assigned_pr  = 


award  = 


awd_date  = 


♦purchase  request  where  the  total  actual  cost  is  greater  than 
the  total  estimated  cost* 

approved_pr  +  {actual_cost}  +  {item_tot_act_cost}  + 
total_actual_cost 

** 

street_address  +  (mail_stop)  +  city  +  state  +  postal_code  + 
(country) 

*SAACONS  line  item  actual  cost* 
actual_cost 

*SAACONS  delivery  date* 
delivery_date 

*purchase  request  that  has  procurement  buyer  approval* 
assigned_pr  +  buyer_approval 

♦purchase  request  that  has  been  assigned  to  a  buyer  by  the 
contracting  officer* 
orderable_pr  +  buyer_assignment 

♦SAACONS  award  download  information* 

awd_piin  +  pr_num  +  splline  +  awd_status  +  awd_date  + 

al_regdeld  +  al_cost  +  desc_text  +  vend_name  + 

vend_addrssl  +  vend_city  +  vend_stat  +  vend_zipcode  + 

vend_phone 

♦SAACONS  line  item  award  date* 

♦format:  DD-MON-YY* 

{legal_character} 
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awd_piin  = 


*SAACONS  purchase  order  number* 

TBD 


awd_status  =  *SAACONS  line  item  award  status* 

{numeric_digit> 

award_date  =  *SAACONS  purchase  order  award  date* 

date 

bar_code_no  =  *property  book  bar  code  number* 

{alphanumeric} 


batch_.no  = 


blank_pr  = 


bldg_no  = 


blk_no  = 


*SOMARDS  batch  number* 

“Buylt” 

♦purchase  request  with  the  requester  and  dehvery  info 
filled* 

requester_userid  +  user_info 

♦building  number* 

{alphanumeric} 

♦SOMARDS  block  number* 

“ARL” 


blk_tkt_dt  =  *SOMARDS  block  ticket  date* 

♦format:  MMDDYY* 
date 
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block  = 


buyer_approval  = 


buyer_assignment  = 


buyer_userid  = 


cancel_order  = 


CANCELED  = 


canceled_pr  = 


certifiable_pr  = 


certification  = 


certified_pr  = 


*SOMARDS  build  block  data* 

tms_cd  +  user_auth_key  +  cmd_dsg  +  update_code  + 
blk_no  +  blk_tkt_dt  +  tot_blk  +  batch_no  +  tot_batch 

*buyer  approval  of  purchase  request* 

[“Yes”  I  “No”] 


** 

buyer_userid  +  saacons_buyer_code 

** 

userid 

*order  to  cancel  purchase  request* 
[“Yes”  I  “No”] 


{canceled_pr} 

♦purchase  request  that  has  been  canceled* 
active_pr  +  cancel_order 

♦purchase  request  that  has  fund  source  approval  or  actual 
costs  approved* 

[completed_pr  +  fimd_source_approval  I  actual_pr  + 
actual_cost_approval] 

♦SOMARDS  certification* 

[“Yes”  I  “No”] 


♦purchase  request  that  has  been  certified  by  SOMARDS* 
certifiable_pr  +  certification 
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city  = 


CLOSED  = 


closed_pr  = 


cmd_dsg  = 


company_address  = 


company_email  = 


company_fax_no  = 


company_name  = 


company_phone_no  = 


company_poc  = 


** 

{alphabetic_character  } 

{closed_pr} 

^purchase  request  that  has  been  accepted  by  the  requester* 
tagged_pr  +  {acceptance} 

*SOMARDS  CMD-DSG* 

MJH 

** 

address 

** 

email_address 

** 

phone_no 

** 

{legal_character  } 

** 

phone_no 

name 
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completed_pr  = 


♦purchase  request  that  has  been  approved  by  the 


comt_ref.no  = 


corrected_pr  = 


corrections  = 


country  = 


cum_btch_value  = 


date_required  = 


delivery_date  = 


desc_text  = 


supervisor* 

@doc_ref_no  +  funded_pr  +  request_date  + 
supervisory_approval 

♦SOMARDS  document  reference  number* 
doc_ref_.no 

♦purchase  request  that  has  been  corrected  by  the  requester* 
rejected_pr  +  corrections 

♦corrections  to  a  rejected  purchase  request* 

TBD 

** 

{alphabetic_character> 

♦SOMARDS  cumulative  batch  total  for  the  days 
certification* 

♦units:  dollars* 

♦date  shipment  is  required  by* 
date 

*estimated  date  for  delivery  from  vendor* 
date 

♦SAACONS  item  description* 
description 


32 


description  = 

desc_text  = 

doc_ref_no  = 

email_address  = 

EMPLOYEE  = 

employee  = 

eor  = 

estimated_cost  = 

explanation  = 

finished_pr  = 


*item  description* 

{legal_character> 

*SAACONS  description  text* 
description 

*purchase  request  document  reference  number* 
“W-”  +  TBD 


** 

TBD 

{employee} 

♦employee  information  -  the  bare  minimum  should  contain* 
user)info  +  {roles} 

♦funding  element  of  resource* 

{alphanumeric} 

♦estimated  cost  of  an  item* 

♦units:  dollars* 

♦rejection,  cancellation,  or  return  explanation* 
{legal_character} 

♦purchase  request  where  the  total  actual  cost  is  less  than  or 
equal  to  the  total  estimated  cost* 

approved_pr  +  {actual_cost}  +  {item_tot_act_cost}  + 
total_actual_cost 
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first_name  = 


fund_source  = 


fimd_source_approval  = 


funded_pr  = 

funds  = 


inbox  = 


inboxjnquiry  = 


inbox_location  = 


item  = 


*a  person’s  first  name* 
{alphabetic_character  > 

** 

jo_no  +  eor 

♦budget  analyst  approval  of  fund  source* 
[“Yes”  I  “No”] 


♦purchase  request  with  a  fund  source* 
partial_pr  +  fimd_source 

♦funding  information  for  SOMARDS  certification* 
tms_cd  +  user_auth_key  +  cmd_dsg  +  update_code  + 
blk_no  +  blk_tkt_dt  +  batch_no  +  rej_rept_director  + 
doc_ref_.no  +  jo_no  +  eor  +  act_amt 

♦purchase  requests  requiring  action  from  user* 

{active_pr} 

** 

TBD 

♦current  purchase  request  location* 

TBD 

** 

@line_item_no  +  description  +  unit_of_issue  +  qty  + 
estimated_cost  +  actual_cost  +  item_tag  +  acceptance  + 
item_tot_est_cost  +  item_tot_act_cost 
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items  = 


item_tag  = 


item_tags  = 

item _tot_act_cost  = 


item  tot_est_cost  = 


jo_no  = 


last_name  = 


line_item_no  = 


mail_stop  = 


name  = 


nomenclature  = 


** 

{item}  +  specifications 

*property  book  officer  inputs  “yes”  item  is  taggable, 
receiving  overwrites  with  bar_code_no* 

[“Yes”  I  bar_code_no] 

{item_tags} 

*line  item  total  actual  cost* 

♦units:  dollars* 

♦line  item  total  estimated  cost* 

♦units:  dollars* 

♦funding  job  number* 

{alphanumeric} 

*a  person’s  last  name* 

{alphabetic_character  } 

♦line  item  number* 

{numeric_digit} 

♦mail  stop  or  department* 

{legal_character} 

** 

first_name  +  last_name 

♦SOMARDS  certification  comment  field* 

{alphanumeric} 
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office_symbol  = 


orderable_pr  = 


ordered_pr  = 
partiaLpr  = 


phone_no = 


po_number  = 


postal_code  = 


pr_authamt  = 


pr_authby  = 


pr_buyerid  = 


*ARL  office  symbol* 

“AMSRL-”  +  {alphabetic_character>  +  + 

{alphabetic_character  > 

♦purchase  request  that  can  be  ordered  by  procurement* 
taggable_pr  +  property_approval 

♦purchase  request  that  has  been  ordered* 
finished_pr  +  delivery_date  +  vendor  +  po_number 
♦purchase  request  with  items  and  vendors  filled  in* 
blank_pr  +  datejrequired  +  priority_code  +  items  +  vendors 

*a  phone  number* 

{numeric_digit> 

♦purchase  order  number* 

TBD 

♦postal/zip  code* 

{numeric_digit} 

♦SAACONS  authorized  amount* 
total_estimated_cost 

♦SAACONS  authorized  by* 

TBD 

♦SAACONS  buyer  code* 
saacons_buyer_code 
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pr_contact  = 


pr_details  = 


pr_item  = 


pr_num  = 


pr_phone  = 


pr_priority  = 


pr_reqdeld  = 


Pi-type  = 


priority_code  = 


property_approval  = 


*SAACONS  purchase  request  point  of  contact* 
requester_name 

♦details  about  the  purchase  request* 

TBD 

♦SAACONS  purchase  request  item  details* 

pr_num  +  splline  +  splum  +  splcost  +  splqty  +  splreqdeld  + 

desc_text 

♦SAACONS  purchase  request  number* 
doc_ref_no 

♦SAACONS  POC  phone  number* 
requester_phone_.no 

♦SAACONS  priority  code* 
priority_code 

♦SAACONS  required  delivery  date* 
date_required 

♦SAACONS  purchase  request  type* 

“S” 

♦request  priority  code* 

*range:01  - 15, 99* 

{numeric_digit} 

♦property  book  officer  approval* 

[“Yes”  I  “No”] 
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qty  = 


receipt  = 


received_pr  = 

reconcile  = 


rejected_pr  = 


rej_rept_director  = 


report  = 


report_type  = 


request_date  = 


requester_userid  = 


♦quantity  requested* 
{numeric_digit> 

♦shipment  receipt* 
[“Yes”  I  “No”  ] 


♦purchase  request  that  has  been  received* 
ordered_pr  +  receipt 

♦end  of  the  day  SOMARDS  reconcile  info* 
tms_cd  +  user_auth_key  +  cmd_dsg  +  update_code  + 
blkno  +  blk_tkt_dt  +  batch_.no  +  tot_blk  +  tot_batch  + 
ty_act_cd  +  cum_btch_value  +  variance 

♦purchase  request  that  has  been  rejected* 
active_pr  +  explanation 

♦SOMARDS  REJ-REPT-DIRECTOR* 

“R” 

** 

TBD 

♦type  of  report  to  generate* 

TBD 

♦date  purchase  request  was  approved  by  supervisor* 
date 

** 

userid 


38 


retum_message  = 


role  = 


room  no  = 


saacons_buyer_code  = 


sole_source_just  = 


special_approval  = 


speciaLpr  = 


splcost  = 


spline  = 


*message  returned  from  SOMARDS  process* 

[“processing  complete”  I  “bad  user_auth_key”  I  “wrong 
update  code”  I  “blk_no/blk_tkt_dt  already  exists”  I 
“accounting  class  displayed”  I  “blk_no/blk_tkt_dt  doesn’t 
exist”  I  “invalid  jo_no”  I  “invalid  eor”  I  “insufficient  funds”  I 
“duplicate  comt_ref_no”  I  “cum_btch_value”  I  “make 
changes”  I  “variance”  ] 

*user  role* 

{alphanumeric} 

*room  number* 

{alphanumeric} 

♦buyer’s  SAACONS  buyer  code* 

TBD 

♦justification  for  using  a  single  vendor* 

{legal_character  } 

♦approval  from  a  special  approving  officials* 

[“Yes”  I  “No”] 


♦purchase  request  with  special  approvals* 
certified_pr  +  special_approval 

♦SAACONS  estimated  item  cost* 
estimated_cost 

♦SAACONS  line  item  number* 
line_item_.no 
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splum  = 


splqty  = 


splreqdeld  = 


state  = 


status  = 


statusjnquiry  = 


street_address  = 


supervisory_approval  = 


taggable_pr  = 


tagged_pr = 


*SAACONS  unit  of  measure* 
unit_of_measure 

♦SAACONS  quanity  requested* 

qty 

*SAACONS  item  required  delivery  date* 
date_required 

♦state  or  province* 

{legal_character> 


** 

TBD 

** 

TBD 

** 

{legal_character> 

♦approval  from  supervisor* 
[“Yes”  I  “No”] 


♦purchase  request  that  has  had  item  tags  attached  by 
property  book  officer* 
special_pr  +  item_tags 

♦purchase  request  that  has  been  received  and  taggable  items 
have  been  appropriately  tagged* 
received_pr  +  item_tags 
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total_actual_cost  = 


total_estimated_cost  = 


tot  batch  = 


tot  blk  = 


tms  cd  = 


ty_act_cd  = 


unit_of_issue  = 


update_code  = 


upload  = 


*the  total  actual  cost  of  the  purchase  request* 
*units:  dollars* 

*the  total  estimated  cost  of  the  purchase  request* 
*units:  dollars* 

*SOMARDS  batch  number* 

*units:  dollars* 

[“0.00”  I  cum_btch_value] 

*SOMARDS  total  block* 

♦units:  dollars* 

[“0.00”  I  cum_btch_value] 

♦SOMARDS  transaction  code* 

[“003”  I  “004”  I  “310”] 


♦SOMARDS  action  code* 


** 

TBD 

♦SOMARDS  update  code* 
[“CM”  I  “NM”] 


♦SAACONS  purchase  request  upload  information* 
pr_num  +  pr_type  +  pr_contact  +  pr_phone  +  pr_reqdeld  + 
pr_authamt  +  pr_priority  +  pr_authby  +  pr_buyerid  + 
{pr_item> 
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user_auth_key  = 


user  info  = 


userid  = 


variance  = 


vend_addrssl  = 


vend_city  = 


vend_name  = 


vend_phone  = 


vend_stat  = 


vend_zipcode  = 


♦SOMARDS  user  authorization  key*  . 

{alphanumeric} 

♦user  information* 

name  +  office_symbol  +  phone_no  +  bldg_no  +  room_no 

** 

{alphanumeric} 

♦SOMARDS  variance  between  tot_batch  and 
cum_btch_value  -  should  be  0.00* 

♦units:  dollars* 

♦SAACONS  vendor  address* 
street_address 

♦SAACONS  vendor  city* 
city 

♦SAACONS  vendor  name* 
company_name 

♦SAACONS  vendor  phone  number* 
company_phone_no 

♦SAACONS  vendor  state* 
state 

♦SAACONS  vendor  zip  code* 
postal_code 
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vendor  =  *vendor  information* 

company_name  +  company_address  +  company_phone_no 
+  company_fax_no  +  company_poc  +  company_email 

vendors  =  *up  to  three  suggested  vendors* 

{vendor}  +  sole_source justification 
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Intentionally  left  blank. 
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